Cisco Networkers 1998

home *** CD-ROM | disk | FTP | other *** search

/ Cisco Networkers 1998 / Cisco Networkers 1998.iso / pc / talks / nwk06a / nwk06a.eml < prev next >

Wrap

Text File | 1998-04-21 | 72.0 KB | 1,102 lines

<HTML> <HEAD> </HEAD> <BODY>   Hi, I'm Chris Lonvick. Welcome to Designing Secure Enterprise Network Infrastructures. What I'd like to do here is get you all started thinking not so much about network security or network infrastructures, but let's take a bit of an analogy and think about that and see if we can't get our hands around the whole problem here. What I've got is a picture of the USS Constitution. It has tons of cannons all over it. It has guns. The Marines are stationed on the thing. We've got - oh, the sailors with the neat little swords and all sorts of things there. If you're the captain of this, what possibly could be your security concerns for this? Obviously not much. Well, what about drinking water? What about food? All of these things are also essential for you to be able to accomplish your mission, whatever that might be. If you run out of any of these things, of course you're going to have to put back into port and replenish those supplies before you can go out and accomplish your mission. So you could have a failure just because of these simple little things. The paramount thing to have is a written policy. We've discussed that in many other Networkers' presentations and you can find this also anywhere else you look about network security. First have a policy, a written-down policy. We've also got three elements that are very well identified and you'll see these also in several other Networkers' presentations: the identity, the integrity, and the audit functions here. I'm not going to go through these in this presentation. But what I want to do is show you how to go through and apply these things to your policies or your procedures and operations. I've identified four areas here that we really need to spend some time with, or you need to spend some time with to make sure you have a secure network. First one is training. This is all the way from the captain all the way down to the lowest deck swabbie there. You continually need to be trained in new areas or to make sure you're up to date with what's going on in the current technologies. The rules - again, they must be applied to everyone and they really need to go - they need to be agreed upon by everyone on the whole ship or in your whole network in order to be effective. Periodic review of your procedures and operations is also critical. People need to come back and take a look and make sure that you're meeting your business objectives. Delegation of authority - of course the captain is fully responsible for everything that goes on on the ship there, but the captain can't be awake and he can't be everywhere at all times. He's got to rely upon officers, the officers have got to rely upon the men under them to make sure that all the procedures or the policies are being met at all times. What we're going to go through here in this session - I want you all to think about this a little bit, or this is what I want you to think about during this session - defining what to protect. Essentially it's going to be anything that could cause problems if you were to lose it or if it were to become corrupted, or to malfunction, and decide how to protect it. There's various ways, and you can think about what is good enough to meet your business needs versus what is the absolute protection of that resource or device. One other thing - think about the cost of the protection versus the cost of the loss or corruption of that resource. The analogy I like to use with this one is a newspaper. You're probably paying 25, 50 cents for home delivery of that newspaper. If it doesn't come some day, what's going to happen? You're going to be out that amount of money. You can go buy one or you can call up and complain and they'll deliver another one later on. It's just not quite the same if it doesn't get there first thing in the morning. What if someone actually came through and maliciously replaced your newspaper with one that they had printed up? Let's say it had the title on it of Cisco's stock selling at $800 per share. We hope that happens next week, by the way, but what if the attacker could predict your reaction to reading that headline? You might go out and do something, in which case the attacker could take advantage of that and his attack could succeed no matter what that could be.  We've gone through the introduction here. What we're going to get into next is thinking about the router or the switch self-protection. We're going to start small here and work our way progressively outward throughout this talk. The next - beyond that is resource protection, thinking about how to protect individual resources throughout your enterprise. Moving beyond that we're going to talk about the entire perimeter of your network. Then we're going to come back and take a look at the whole thing at a plane above it, thinking about how to sustain that network security. Come back after that and talk about how to validate that you actually are sustaining your network security there as well, and we'll wrap the whole thing up with some conclusions in the final section. Let's go ahead and get into this a little bit - The Router/Switch Self-Protection. I had originally wanted the graphics artist people to get that - the Zena, the Warrior Princess thing with the swords up there and, you know, I looked around for that one on the Internet as well and found out that all those photos were copyrighted. Got to respect that and actually I asked around and found out, no, we're not planning to buy that company anytime soon, so I'm stuck with the sword and the hatchet thing there. Let's talk about first, the intruder attack points. Of course any burglar is going to know where the security weaknesses of your house could be if they target your house to get into. Of course they're going to try the front door. They're going to go around and try the back door. They're going to try possibly some windows or any other point that could potentially let them into your house. There are some well-known attack points with the routers as well. We're going to go through these things one at a time, step through them so you can see how to barricade each of these attack points. First off let's talk about the administrative interface. This is essentially the front door. We're going to talk about the password protection and password encryption. First thing, the banners. No, this is not the banners you wave around. These are the login banners, what gets displayed when you log into the router. Think about these, spend some time with it. There is an RFC, I think it's 2096, that talks about the site security handbook. In this it goes through and tells you what is an appropriate login banner on your network devices. There's a lot of legal discussions about these things. Please don't use the word "Welcome." This is defined in that RFC. Let's talk about the native passwords on the routers here. As you see here, the configuration snip, we've got line console 0. The next command or the next configuration command is login. What we're saying here is that the - if you access the console port you must authenticate. Without that line there, anyone coming up and pressing the enter will automatically get to the router prompt. This is probably not what you want to happen. Put that login command there. The next line defines the password for that console port. Right after that is the exec-timeout, one minute and 30 seconds. If you apply this to any of the lines or the VTYs, then if you let that session sit there idle for a minute and 30 seconds, the router will automatically time the thing out. This is probably a very good practice to get into. What we see there when the console comes up is someone's pressed the enter key, comes up with user access verification and requires a password. If you type it incorrectly you will get the router prompt.  We can talk about now the service password-encryption command. This is going to encrypt the password. What you saw before was that that password was in cleartext. What this command does is it takes that cleartext, runs it through an algorithm to flip some bits on it and it comes out and it won't display in cleartext any longer. Now this one is a Cisco proprietary encryption method. It can be reversed so that it can come back to the cleartext password. There's several reasons for that. Let's take a look at how this can work in your network. We've got a before and we've got an after type scenario here. And the first one starts out with hostname Router and the enable password is displayed in cleartext. If we go through and just add service password-encryption command to the configuration, we now look down. The enable password has that 7 appended to it and then a totally different string. Again, logging in using the password one4all will get you into the router, but at least now if someone is looking over your shoulder they won't be able to see what the cleartext password is. It's always a good idea not to let someone you don't trust look over your shoulder. They might be able to memorize this thing or write it down. What could be better than that? The enable secret 5 password. This uses an MD5 hash to take the cleartext password, run it through an encryption algorithm or a hashing algorithm to come out with the signature of that password. This is one way. There's no way you can take that signature and come back to the cleartext password. We use this so that you can be fairly well assured that the password you put in will not be readable by anyone else, even if they can get hold of it. We can use, just like with the password 7, cut that from some other window if you have a multiwindow terminal, and then paste it into the configuration of the router. We'll see how this works in just a couple of minutes, but let's see how this works in an actual configuration here. We start out with hostname Router. This is, again, a before and after scenario, and we have the enable password 1forAll here. If we go through and we have to - in the actual configuration you have to say, "No enable password" and then come back and say, "Enable secret 5," you type in your cleartext password and it will come up with - I'm sorry, you type in enable secret and then your cleartext password, it will appear in the configuration snip like this, an extremely long signature of that password. Okay, a couple of things to think about here. Physical security is always required with this. Someone can take your router away, or if they can access your router they can get into it and they can change the passwords to see - to meet whatever they put in, or they can read the configurations. We've published these methods so that people can get into their routers if the administrator gets hit by a truck or whatever. So, always make sure that you guard your passwords pretty jealously, you lock up your routers. There is a certain type of attack, the replace-the-router attack where someone could actually come in, take your router out, look at the configuration, put it into their own router there, cut that password string, the enable 5 password, paste it into the new router after, let's say, they've turned on debugging for something, put that router back in service. The administrators are going to know that that router was down for some time. They'll be able to log back into it using the correct password. They're going to start thinking, "Hey, maybe everything's all right with this," where, in fact, the attacker is now getting debug information. Again, just a word of caution here. Always lock down the routers, make sure the wiring closets are locked so that attackers cannot get physical access to the routers. Also, I'm sure that everyone's gone through this a time or two before. You're sitting there, you're bringing up a new router. What? You've got everything written down perfectly on a piece of paper. You're going through it. You've got addresses, interface, subnet masks, everything else, and then all of a sudden it asks you for the enable password. Your mind locks up. You can't think of anything. What do you do? You type in Cisco or Pancho or something else. Of course the attackers are going to try these just as well. Please don't use these passwords. Use something that you sit and think about. It's a well-known fact that Rodin was actually thinking, trying to come up with a good password when he came up with his idea for this sculpture called The Thinker. We've got some authentication mechanisms here. First, what we've talked about in the past has been the local database. This is the passwords that are locally stored on the router. If we take these passwords or the authentication mechanism and shift them out to a central location, we call this a centralized database. This is what Kerberos, TACACS, RADIUS, and the one-time passwords will all use. There are some good reasons to keep localized databases on the routers. There's a lot of other good reasons to move it off to a centralized database. If you have a lot of routers, or perhaps you have a very complex configuration, or you absolutely are required to use one-time passwords, then it's always very good to have a centralized database of your authentication. Let's take a look at this. I'm going to go through some examples here and I'm going to use TACACS+. This is just what I had working for me. All of these configurations will work very well also with RADIUS or Kerberos, and you can get into the one-time passwords as well. What I've got here is an authentication mechanism for IOS, and I'm using IOS Version 11.2. Let's walk through this configuration and make sure that everyone's familiar with this. First thing, we've got that service password-encryption. This is going to, wherever it finds a cleartext password, run it through that encryption type 7 so it'll come out not cleartexted any longer. Hostname Router - yeah, my mind was in brain-lock when I came up with this configuration, a aaa new-model. Last year Lowell Grant went through a very good explanation why you need this aaa new-model in order to come up with TACACS+ or use TACACS+ in the IOS. The next three lines are pretty much the meat of this configuration snip, this part: the aaa authentication login billy. What we're doing here, we're defining a list of authentication mechanisms that the router will use and the order that it will try them out in. The first element of this list is TACACS+. If that fails - this is not if it returns a negative response, this is if TACACS+, the TACACS+ server cannot be found, then the router's going to flip on and use the next mechanism, and this is what we call enable. We'll go through exactly where this applies and how it gets used just a few minutes here. The second line there of these three, the aaa authentication login bobby. Okay, this is a different list that we're setting up here. First it's going to, again, try TACACS+. If it cannot establish a session with the TACACS server, then it'll move over to a local database authentication mechanism. The third line is the enable secret 5, and, again, the very, very long string. I cut that out because it just kept on going and going and going. Down at the bottom, the last line of this configuration, username bill, and, again, it's been encrypted with the type 7 and some string out there. I think I used junk there so you can see how that thing gets sort of convoluted as it gets thrown in here. Let's take a look at the rest of the configuration and see how we can apply this. The TACACS-server host 10.1.1.2 - I have a very simple network that I'm setting this up in - it's going to define where the TACACS server is, and, of course, you can have multiple of these and then you're going to need to keep these things synchronized across your network. TACACS-server key - this is very specific for TACACS. The - If you put this command in, the session from the router to the TACACS+ server will be encrypted. It's not a very strong encryption method, but at least it'll give a attacker who can capture this some pause. They might or might not be able to decrypt it depending upon how much of a string they get or how far they are able to capture this string throughout. Now we're going down to the last set of lines here and we're going to apply our authentication mechanisms. Let's look at line con 0 here first. We've got login authentication billy. This is the one - oh, we also do this with the line auxiliary 0 here. So both of these things we're applying this - the list billy to the console and the auxiliary lines. Again, first it's going to try to use TACACS+. If it cannot establish a session with the TACACS+ server, it will come back and try - it will prompt the person trying to log in to just enter the enable password. The VTYs are now set up differently. They're going to use that list bobby, which is first. Again, going to try to use TACACS+. If that fails then they're going to try and use that local password, which we defined bill, and the password for that. Where could you apply this? Let's say that you don't want anyone to send the enable password in the clear across the wide area network, but you know that sometimes this router's going to be yanked out of service, all the connections to it are going to be disconnected. So in that case, if the thing is yanked out of service, it will not be able to establish the session to the TACACS+ server. One of the local administrators, one of the delegated people, the people who locally administrate this router, might be able to set up a local area network to it and just telnet into it and use that password for bill to get into the thing. Otherwise, if they're sitting at the console then they could use the enable password. Let's take a look at this very similar for the PIX. It's important to keep in mind that the PIX does not support a local database. It is all remote database here, so if you turn on an authentication mechanism, and you don't have to on the PIX, then you're going to need to set up a remote - a centralized authentication device out there, a TACACS+ or a RADIUS server. Let's take a look at this configuration snip. I'm using the PIX version 4.0.7. There's a couple of differences between the 4.0.7 or the 4.0 version and the 4.1. Not too many for what we're getting into here, but be aware of them, and you've got a lot more options and stuff in 4.1. Let's take a look here. The enable password, and I've got this - sorry, I've got this flipped here and telnet password and enable password on the side should be flipped of course. Enable password, some crazy string there, and, again, encrypted. This is pretty much the same mechanism. This password, you enter it in cleartext and it gets encrypted so that you can - no one's going to be able to look over your shoulder. Same thing with the - just the password. That password is going to apply to the console port and to the telnet sessions that are permitted into the PIX. Looking down at that TACACS server, again, we're just defining the location of the TACACS server and optionally behind it use the key. This, again, if you use the optional key it will encrypt the session to the TACACS server using that key. Again, not a real strong encryption mechanism, but it might be good for something out there. Next couple of lines here, aaa authentication telnet. What you're doing with this one is anyone attempting to set up a session through the PIX using telnet will get an instream challenge. It's saying that anyone going outbound and the challenge is going to be done via TACACS+. So you have to make sure your TACACS+ server is out there and working before anyone's going to be allowed to use telnet outbound. Same thing with FTP and the same thing with HTTP. Telnet and FTP, these are console sessions, so you're typing in things and getting responses back on a console. HTTP, it's going to come up with a browser screen and prompt you for putting in your username and your password there. All three of these can be compressed down into one line. Rather than using the telnet, FTP, and HTTP keywords, you can use the "any" keyword. The downside of that is before you could use any protocol, let's say SMTP or POP-3 or anything else, you've got to be authenticated. There is no instream authentication for POP-3, SMTP or any of the other protocols out there. So your users would have to first go through, establish a telnet session - sort of going through the thing, they don't care if they get there or not - but at least they'll get authenticated and the PIX will put them in the user authentication table, the UATH table there. Once that happens then they will be able to use the SMTP or POP-3 or whatever else they want to. This seems to be quite a bit of a, oh, negative influence on the people that are trying to get through these things who are starting out with non-telnet, FTP or HTTP sessions. Many people just like to go ahead and use specifically these three. Okay, I've got no SNMP information out there. That's just because telnet 10.1.1.2 255.255.255.255.  That's going to lock it down and say the only device that can telnet into the PIX is going to be that 10.1.1.2 device. No one else will be able to telnet to the PIX. Okay, let's talk about the Centri authentication. Primarily it uses Windows NT domains to authenticate people to be able to go through the Centri. I don't want to say this is the only one. This is the primary method. There's also a centralized database on the Centri so that if people coming from, let's say, a UNIX machine or someone that's just not logged into the NT domain, if they want to establish a session going through the Centri they'll be prompted, again, in those same three instream mechanisms, telnet, FTP, and HTTP, they'll be challenged to provide their username and password. Those can be locally set up in the Centri and then if they meet that they'll be allowed to go through. Otherwise, like I said, the primary mechanism is to use the NT domain. They'll be able to log into the domain and their credentials will be passed from the primary or the backup domain controller all the way through to the Centri if they try and establish a session outbound through the Centri. Okay, a couple things. This is not designed - don't design with these in mind - but it's a couple things to be aware of in the future. IOS at some version in 11.3 will use better mechanisms for the enable password. It'll be very similar to what you can use for the login passwords right now. This is - what, take the - use TACACS+, RADIUS, or Kerberos to actually set up - or the one-time passwords for the enable password. Also the PIX, they're changing that so that it will start using additional authentication mechanisms for the console and the enable passwords as well. Let's talk about Kerberos for just a second. There's a lot of people that are using this. They're very satisfied with it. It takes a lot to get this thing going. I attempted to do it on a couple of SPARC workstations where the - I got the KDC running on those SPARC workstations. This worked out fairly well. It was pretty easy to set this thing up. It came back and told me everything was working properly, things were going at the logs as I expected them to be. I set up a router to use Kerberos authentication first and I finally got that thing working. It was very, very heavily dependent upon DNS and the correct time throughout the network. First, DNS - I had tried on the KDC to get some things going a little bit fast, so I just used the host's table and it said, "No, it's not going to do that." So I had to go back on the router and align things properly with what the DNS was saying was correct. The time - I found out that the SPARC workstation's time was set to Central and the router's time was set to Pacific. So I went through and changed the skew on the clock on the KDC, made it something like 500,000 seconds, ten years' worth of slew on the thing, and it started working okay after that. Beyond that - that's an authentication mechanism. Beyond that you can also use it to encrypt your telnet sessions to the router. This is not only telnet, but also the R login, the R shell, and all the other mechanisms that you can use to get to and control a router. It's a very, very good, strong encryption mechanism. Strong is a relative term today, but it is good and strong, uses 56-bit DES right now, and the - it will go through this instream. That means that it protects the authentication and protects the session so you can be confident of confidentiality, integrity, and strong authentication through this. Okay, one-time passwords - this you can use to set up a session to the router or to any network device, and you'll be prompted. I'm sure you've all seen the key cards, the little token cards that have either a number displayed across them all the time or something that you punch in a number that you get as a challenge - you punch in the number and it comes up with a response. You can put these things in. We support these in CiscoSecure. So it's a additional mechanism. If someone's tapping the wire they're not going to see this password go across in cleartext. Okay, restricting telnet access. Let's talk about this for a few minutes here. We talked about that on the PIX. Let's take a look on IOS and see how that does also. Access-list 12 permit - what we're going through here is saying - specifying exactly who can telnet into the router. We're defining that to be the 172.17.55 network. Hopefully this is where you've got all your administrators set up so they can telnet into the router. Now we go through and apply that to the VTYs, all the VTY ports. Access-class, special command for who can telnet in. Access-class 12 in. We've also got another keyword "out" so that once a person establishes a session on the router, they will not be able to go out with another telnet session unless it meets a different access list. So that's something that you can think about to further confine the authorized administrators. Let's talk about SNMP access control. It's very similar to what we just talked about with the telnet control into the router. Access-list 13 - we're permitting specifically this one device. Again, we're permitting in that second line, permitting another specific device, and with that third line we're now saying snmp-server community public. Public is the community string. That's the password for SNMP. This is the default password that is specified in the RFC. Beyond that, RO is for read only. The other option there is read/write. It's a good thing to make this thing read only. And then finally the final keyword out there is 13, which matches back to your access list. So only these two devices that you've defined will be able to send SNMP queries to the router. The router will look at that and see, "Yeah, this matches. It goes back to or it matches the access list so I can send the responses back to them." If it doesn't, the sessions will be ignored and dropped. Using "public" as your community string is not a very good thing to do. I've seen a lot of articles in Frac Magazine specify or telling people go ahead and try public. Again, try Cisco, Pancho, several of the other well-known passwords, community strings to try and take access - or try to take control of the router there. Version 1 of SNMP does send these passwords in cleartext. It also sends the responses back in cleartext. This is a known problem with SNMP Version 1. Version 2 addresses these things. It also puts in a policy reference saying, "This device can do read/write. That device can only do read only. This device can only do read only and is limited to these certain things." Unfortunately SNMP Version 2 has not been widely accepted. People are pretty much waiting for version 3 and then they're going to throw all their efforts at that when it comes about. I guess we can say that the SNMP effort has been going on for a long time. A lot of people have a lot of great ideas to go into that thing, and they're trying to pull it all together now. The identification protocol - several times a year we get some questions about this. On paper at first glance it looks really neat. Let me say some negative things about this at the end. Let's go through it here real quick. You might see this on UNIX machines as the ident D process. First, a device is going to telnet into the router, and if you turn this on - proofing this thing I found out, I realized I did not include the command in here, which is just as well. I'd recommend not using this. First, a device is going to try and telnet into the router. The router is going to put that thing on hold, come back, and establish a ident process or ident session back to that host because it knows the source of the session and the source and destination port numbers. So it's going to send back a query to that thing saying, "Who is this?" If everything's working correctly that device is going to send back, "Well, that's Chris. So hey, it's okay." If everything gets satisfied correctly the router will take that telnet process that it had on hold and then allow it to proceed. It's the syn - after everything happens it'll send back the syn/ack and things will go from there. Within the RFC, and this is RFC 1413, I've included the security concerns as a - in the speaker notes of this presentation. You might want to go through that or you might want to get a copy of RFC 1413. It starts out by saying, "The information returned by this protocol is at most as trustworthy as the host providing it." It pretty much goes downhill from there, saying you - it can be spoofed fairly easily. So this is something you can use. I don't know, I've never seen anyone actually using this in a real network before. Okay, let's talk about some resource deprivation attacks. Within the IP protocol there are four different applications, if you will, that have been defined. The first one is the Echo protocol, and these things apply to both TCP and UDP. So the first one, Echo - if you establish a TCP session to a router or some other network device on port number 7, every key that you type in will be echoed back to you. This is a great thing, okay. The Discard protocol - if you establish a TCP or UDP session over to a router, every key you type in will be discarded by the router. I usually bundle up all my excess e-mail and start up that session number 9 and just sort of dump it down there. Number 13 is the Daytime. If you set up a TCP or UDP session to a router on port number 13, the router's going to respond back with what it thinks the date and time are. Okay. None of these things are pretty dangerous by themselves unless something like you and 50,000 of your closest friends all establish these sessions to the router at the same time. The router will pretty much just sit there and think about how to handle all of these sessions coming to it. The - one of the nastier ones here is this fourth one, character generation, or Chargen. If you establish a TCP session on port number 19 to a router, the router will take all those e-mail messages that I shoved to it on the Discard port and will continually send you back one character at a time. This is actually an ordered progression of characters. If you start it up, the only way to stop it is by killing the TCP session there. If you allow it to go, the router's going to spend a lot of cycles continually sending you back one packet, one character at a time. Okay. The really nasty thing about this is that in a UDP datagram there's no response, there is no implied session about the thing. Attackers have been able to craft packets. Let's say they come from this router over here and they're going to this router over here and they say "UDP Chargen." So this router now continually sends back packets to the other router, which is just going, "Hey, where did this stuff come from?" It's pretty easy to turn these things off. Why would we have these things turned on to begin with? It's required in RFC 1812. To be a real Internet-compliant router you've got to support certain things. Go through, turn these things off. No service udp-small-servers and no service tcp-small-servers as well. This will make the router not listen on these ports. It won't deal with this stuff anymore. Another one is the finger service, TCP and UDP 79, although it is pretty much just used on TCP 79. Turn this one off with the no service finger as well. Attackers can use this to find out who is logged in to a network device at any given time. If they can get the information about usernames, they'll be able to try those things first. It is usually good to do no service finger on the routers. ARP control - this is something - it's for the control freaks out there. If you have a very small network and you don't want anything to happen without you knowing about it, you can go through and statically define the IP address with the Mac address. In this example here the router is going to know always that that device, 172.1.1.99, is at that Mac address. It won't have to ARP for it. It won't have to go searching for it. Someone else can, yes, turn on their machine with the same IP address, ostensibly a different Mac address, and there will be conflicts between these two devices. The router won't see that conflict because he's not looking for it. It's not doing anything, but it will know for sure that that one device is the only one and true 172.1.1.99. We've gotten some requests periodically also, "I want these people to be able to do this, but the real administrators to be able to do this." This is quite often operations people. You want them to come in, clear the interfaces or do something else. Yes, we've got 16 levels of administration on the router. Let's take a look at this configuration snip here. Privilege level -or privilege exec level 9 show. What we're doing here is we're defining the level 9 administrators and we're applying the command "show" to that level. That means it will not be available to anyone below level 9. It'll be available to level 9 and above administrators. This means if you normally just log in at the level 0, the user level, you will not be able to enter the command "show." Right after that, enable secret level 9, then the password, and finally the enable secret 5. This is the level 15 password, the default-authorized administrator into the IOS. Looking at a session to that router, starts out with you're in enable mode, show priv. Comes back and says your current level is 15. You are the top-level administrator on the router at that time. If you disable and come back in enable 9, now it's going to ask you for the level 9 password and you can enter that and you'll be at level 9. You can do show priv because that show command has been applied to you. It will tell you that the current privilege level is 9, and, again, this is very effective for operations people that you want to be able to clear interfaces or clear counters or something like that, but not get into the configuration. Audit Trail - let's take a look at the IOS syslog audit trail here. Let's start in that middle box, the actual configuration snippet there. Version 11.2, service timestamps log datetime localtime show-timezones. And you've got options out there, you might as well throw them into the thing. The last line there, logging 10.1.1.2. This defines where the syslog server is that the router will bundle up these messages to and send them to it. Moving up to that top box on the UNIX machine, this comes up and it says, let's go ahead and take a look at the log file there and I've called it cisco.log. Comes up, says February 17 - this is looking at the syslog file on the UNIX machine. February 17 21:48 - sure enough, that was the date that I did this. Gives the address that the message came from, has a star or an asterisk out there, March 2, 11:51 and that's kind of strange, and then after that it comes up with the actual message saying that it was configured. Checking the date on my UNIX machine, sure enough, couple of seconds later it gives me the correct time. Going back and logging into the router, that lower blue box there - if you do a sho clock on that the router comes back and says, "Hey, look. I absolutely know that it's 11:53 a.m. Central Standard Time, March 2, 1993, by the way." This is a little bit off, of course. The two times are not synchronized and that's what that asterisk means right there, or actually in both places. The asterisk means that it does not have an authenticated time source, so it's just using its local clock on the router. Of course you want to synchronize these things. You want to run NTP across your network so that you're not left sitting there after the barn burns down trying to figure out well, you know, what happened first? Did the lantern fall over before the horses ran out or after the horses ran out? Synchronize your clocks across your entire network and you won't have to be thinking about, "Well, if I move this up and move that down, then the clock skews on these things are here and there." Don't do that. Synchronize the clocks and get your logging messages going. Again, pretty much similar thing on the PIX syslog looking down at the lower box, the configuration there. Down at the very bottom of that syslog output 20.6. This is facility and level. We're starting at level 6 here, we're defining level 6. That's everything except the debugging messages. This is quite often way too much information for everybody. Usually it's at level 3, which is informational, and above up to level 0, which is - I believe it's system unavailable. The facility there, if you add 16 or if you take away 16 from that number it'll tell you the actual facility. Like, it'll start out at facility 0 for a - using a 16.3 in there. Quite often the UNIX machines require that to come in at a specific level. So you need to think about that and match that up when going to a specific syslog server out there. Taking a look at the top of that thing, tail the PIX log. It says pretty much the same thing. One difference you'll note here is that the PIX is not keeping wall clock or day clock. It will just put in the clock - or the syslog mechanism will actually put in the clock right there. So what do we do with all of these syslog messages? Just like everyone else, once a month you go through and delete the things because they're taking up a heck of a lot of log space or disk space on your machines. No, that's the wrong answer. Get some automated tools to parse these things for you. Syslog messages, yes. They can take up a ton of log space and it's very tedious to try and go through these. There have been some real good efforts on some free products out there that will go through and munge through this to make a report for you, or we've got as an example here Cisco Resource Manager, which can show you in HTTP format - it can run on a UNIX machine and come up with HTTP session, which will go through and review the logs for you. It'll come up with summaries. It'll come up with reports and, in fact, summaries of the reports. This is pretty much like going to the admiral after you come back from your mission out on the ship and say, "Hey, you know, day one I did these things," and the admiral's going to go, "No, no, no. Just give me the summary of this." "Fine, here you go. For all the 30 days I did this." Comes up with some very nice reports on the things. By all means go through and review those reports. You've got an automated tool to munge the stuff down. At least pay attention to that. Okay, let's move outwards a little bit now. We've gone through how to protect the routers, the PIX, and the other devices out there. Let's take a look at how we can apply that and some other things to actually protecting some additional resources in your network. Let's start out with some of the more common threats here. First one is spoofing. This has gotten a lot of press lately. What happens in spoofing is we've got this device out there, 172.16.42.84, obviously the evil device out there. Who is crafting a packet and sending it in through your boundary router, through your first line of defense there towards that machine 10.1.1.2? And the crafting part of it is it's saying the source is 10.1.1.1. The router would normally only look at the destination of that packet. It's going to see yes, it is defined to go to 10.1 network, so it will forward it all the way in there. This is not a good thing if you're not expecting this. A way around this is to put in an access list. We've got it down there at the bottom of the configuration snip, says access-list 111 deny ip 127. Should there ever be any packets coming from the 127 network? No, of course not. The second line of that deny ip, and then you put in the address for your protected network or networks there. Of course you're going to need - after everything else you're going to need an access-list 111 permit any any just to fill that thing out. Then you're going to go back up and apply that as an inbound access list on the external interface, and that's going to be the serial interface there. It's going to look at packets such as the one that's been crafted, look at it and say, "No. This one does not - should not be coming in." So the packet's - or the router's going to drop that. There's also another line here, the no ip directed-broadcasts. This has gotten some press pretty recently. Packets can come in from the outside which tell a network device to split this up and send it to broadcast address on a destination network. Again, you probably don't want this all the time. Certain situations you do, especially if you have some multicast or multimedia applications going on, but as a resource protection if you know that's not going to happen on some internal network, turn it off. ICMP types of attacks - these have gotten some press recently, various things. We can get around this, again, with another access list. The example here is access-list 101 permit icmp any any, whatever you want to put in there, the type and the code. What I've got from RFC 792 right here are all the various types. The ICMP ping starts out with type number 8 and then the response is type number 0, the echo reply. You can go through and figure out which of these you want to allow into your network and which ones - which responses you want to allow out. I've seen some people say, "Cut them all off. ICMP is just evil, especially at the perimeter. Cut it all off." A lot of things will not work in that instance. The pings will not work, the trace route will not work. Various other things won't either. It's your decision whether you want to turn this on or off. Mostly what I've seen are people going through there figuring out exactly which ones they want to have turned on, and specifically only turning those on. A couple of extra things right here. The - let's see, if you look at type number 3, destination unreachable messages, those are sent out from a router. When a packet comes in, the router knows that that destination, either a network or a specific host is unavailable, the router will send back, "No, can't send that packet. I can't complete this session for you, and here's why." It'll give you the type or the code with that. If you put this configuration command onto an interface, IOS is not going to send the IP unreachables out there. This is a piece of information that an attacker could use to exploit a known problem or a known hole in your network with - by knowing that some network is down or some specific host is down. So put that thing on and you can feel a little bit more comfortable with that. The other one there, no ip redirects - ip redirects are good in certain instances. For perimeter protection? No, they should probably be turned off as well. You apply that to an interface and now the IOS will not accept an ICMP redirect from external sources. Source routing - you've probably heard of this one in popular press as well recently. This is where a external device sends a packet in claiming to be some IP address that's not in the normal routing tables. There's good reasons for this. It was defined in RFC 792, the Internet protocol, to allow some host out there who's been moved - this is the first thoughts of IP mobility - some host that's out there can put together a packet saying, "I really am part of this network and here is the path to get back to me," and it'll loop around. In this situation here the private network is being protected by some router. Somewhere else we have the real network 10.16. If you're not expecting source routing or source-routed packets to come into that network, apply the IP source - no IP source routing command to the external interface and that'll look at the IP options there, identify the source routing of that, and immediately kill those type of packets. In this configuration you see we are actually allowing 10.16 packets in, but not if they are source routed. </BODY> </HTML>